-
Notifications
You must be signed in to change notification settings - Fork 31
phd: check exit status of commands #1054
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
similar to std::process::Command: if a command fails with status, we should report that more proactively. further, some commands are expected to exit with status in tests, so adjust test expectations to match the new regime.
| // whether the guest thinks it's running on a Hyper-V-compatible | ||
| // hypervisor. (Whether any actual enlightenments are enabled is another | ||
| // story, but those can often be detected by other means.) | ||
| let out = vm.run_shell_command("systemd-detect-virt").await?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
with this change, the shell command completes with status, so this change ends up being a motivator to detect the hypervisor in a more robust way. yay!
|
THANK YOU |
hawkw
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is great, let's get this merged so i can stop being scared all our PHD tests are passing by mistake
| self.vm.guest_os.shell_command_sequence(self.cmd); | ||
| self.vm.run_command_sequence(command_sequence).await?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm, it occurs to me that this could maybe be jammed together into a method on self.vm, not that we are currently calling it anywhere else...
| // reported in dmesg either it's genuinely not detected, it's a very old | ||
| // Linux, or it's a new Linux and dmesg text has changed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i suppose it could possibly also have fallen off the end of the dmesg ringbuffer if something is spewing out a ton of errors perhaps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh god. file that under "conditions i never want to think about". but yes.
| // For reasons absolutely indecipherable to me, Alpine (3.16, kernel | ||
| // 5.15.41-0-virt) seems to lose some early dmesg lines if booted with less | ||
| // than four vCPUs. Among the early dmesg lines are `Hypervisor detected: | ||
| // Microsoft Hyper-V` that we look for as confirmation that Linux knows | ||
| // there's a Hyper-V-like hypervisor present. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- What
| // the file should still exist on the target VM after migration. | ||
| let lsout = target | ||
| .run_shell_command("ls foo.bar") | ||
| .ignore_status() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since we're asserting on the output of ls below, it's mildly more interesting to try ls and get whatever it did print in the error w/ assert_eq!() instead of "ls exited with 1 but we don't know anything more about it".
this isn't super important but iirc i'd broken the test in a really confusing way where this helped explain what was happening, rather than just saying the right thing wasn't happening.
similar to std::process::Command: if a command fails with status, we should report that more proactively. further, some commands are expected to exit with status in tests, so adjust test expectations to match the new regime.
a billion years ago I opened #797, then sixish months ago I closed 797 with the intent to refresh (.. rebase) it on a current Propolis commit. last week we found out I forgot to actually do that, and so this actually does it! let's get this in this time, instead of not lol
I'm a little surprised that this built cleanly, and I cannot currently run phd locally for Weird bhyve Issues I Need To Go Debug, so I'm leaning on CI for the check in
phd-run.